🟡 [Medium] RNG fix deviates from the file's own (and the repo's dominant) zero-then-init idiom
💡 SUGGEST convention

The fix is correct: wc_FreeRng() dereferences rng->status, rng->drbg, rng->drbg512 and hands rng->heap to XFREE() (wolfcrypt/src/random.c:2615-2680), so pairing an unconditional DoExpectIntEQ(wc_FreeRng(...)) with a conditional ExpectIntEQ(wc_InitRng(...)) really did free garbage off an uninitialized stack WC_RNG. And a failing wc_InitRng is safe to free, because _InitRng() does XMEMSET(rng, 0, sizeof(*rng)) at random.c:1838 before anything can fail. So there is no bug here.

The concern is that the PR fixes the asymmetry from the wrong end, and in a way this file uses nowhere else. Every other handle in test_signature.c follows the standard idiom -- zero the struct, init conditionally, free unconditionally: ecc_key (XMEMSET(&ecc, 0, ...) at lines 59/253/686 + ExpectIntEQ(wc_ecc_init(...)) + DoExpectIntEQ(wc_ecc_free(...))), RsaKey (lines 104/555/742), and falcon_key (line 182). The zeroing is precisely what makes those unconditional frees safe. WC_RNG is now the sole handle in the file that is left uninitialized and instead relies on the init macro never being downgraded.

That also matches the wider repo: across tests/api/, XMEMSET(&rng, 0, sizeof(rng)) appears 226 times in 29 files and ExpectIntEQ(wc_InitRng 324 times, while DoExpectIntEQ(wc_InitRng appears only in these 7 new lines. A zeroed WC_RNG is safe to free -- WC_DRBG_NOT_INIT is 0 and WC_DRBG_BANKREF is 4 (wolfssl/wolfcrypt/random.h:346-352), so the WC_RNG_BANK_SUPPORT early-return in wc_FreeRng is not tripped.

Secondary effect of the chosen approach: wc_InitRng() now instantiates a DRBG and draws entropy even when the test has already failed and every following assertion will be skipped. Harmless on CI, but it is wasted work on entropy-constrained targets and is the opposite of what the skip machinery is for.

Suggestion:

Recommendation: Prefer adding XMEMSET(&rng, 0, sizeof(rng)); at each of the 7 sites (lines 185, 307, 404, 481, 642, 691, 777). Either keep ExpectIntEQ for the init -- matching the 324 other call sites and the ecc/rsa/falcon handling in this very file -- or keep DoExpectIntEQ and add the memset anyway as defense in depth, so the free stays safe regardless of which macro a future refactor or merge-conflict resolution leaves behind. If the DoExpectIntEQ form is deliberately preferred going forward, say so in the PR so the repo can converge rather than carry two idioms. Note separately that the same conditional-init/unconditional-free asymmetry exists in other tests/api/ files that lack the memset -- worth a follow-up sweep, but out of scope here.